If you’re wondering what I’m talking about, I’ve got an example for you in the image below:

These messages, printed as notices, warnings or upon successful / unsuccessful action can be very useful. With this said, we have a few notification types in Magento we can use:

Notice

Mage::getSingleton(‘core/session’)->addNotice(‘Notice message’);

Success

Mage::getSingleton(‘core/session’)->addSuccess(‘Success message’);

Error

Mage::getSingleton(‘core/session’)->addError(‘Error message’);

Warning (admin only)

Mage::getSingleton(‘adminhtml/session’)->addWarning(‘Warning message’);

Output errors from a controller

As there is no point in calling any of these from your view files, i’ll show you an example of setting such error message from a controller.

<?php
class Inchoo_Notifications_IndexController extends Mage_Core_Controller_Front_Action
{
	public function sendAction()
	{
		try
		{
			$mail = new Zend_Mail();
			$mail->send();
		}
		catch (Exception $e)
		{
			Mage::getSingleton('core/session')->addError('Error sending mail');
		}
		$this->loadLayout();
		$this->renderLayout();
	}
}

Note that the $mail object doesn’t have any parameters set (subject, recipient, etc.). This is intentional, so we get our exception section to fire off. When you visit the URL of this controller’s action, you should get something like this:

You could use this kind of error reporting, not only for printing messages for customers from your custom controllers, but also during development. You could also append an exception message:

catch (Exception $e)
{
	Mage::getSingleton('core/session')->addError('Error sending mail ' . $e->getMessage());
}

This is pretty much it from working examples for notification system. Play with it a little, it can be pretty useful. If you want to get an insight as to what makes this magic happen, continue reading.

Under the hood

What part of the code actually outputs these messages? Well, if you were to open lets sayapp/design/frontend/base/default/template/page/3columns.phtml file, you would find something like this:

//line 47 starts below

	 echo $this->getChildHtml('global_messages') ?>
	 echo $this->getChildHtml('content') ?>

Notice the $this->getChildHtml(‘global_messages’) section? The getChildHtml() method is calling a block with name set to ‘global_messages‘, from it’s page layout file, in this case – page.xml. Let’s open it.

app/design/frontend/base/default/layout/page.xml

//line 89 starts below
<block type="core/messages" name="global_messages" as="global_messages"/>

As we can see, the block being called here has a class of Mage_Core_Block_Messages. Let’s go there, to get deeper insight as to what happens. Logic for adding messages is here:

//line 152 starts below
public function addError($message)
{
	$this->addMessage(Mage::getSingleton('core/message')->error($message));
	return $this;
}

While we retrieve messages when this block prepares it’s layout:

//line 78 starts below
public function _prepareLayout()
{
	$this->addMessages(Mage::getSingleton('core/session')->getMessages(true));
	parent::_prepareLayout();
}

If we trace getMessages method, we’ll end up in Mage_Core_Model_Session_Abstract. It’sgetMessages() method is what retrieves messages we have stored in the session. A good example of using different class than ‘core/session‘ for notification messages isMage::getSingleton(‘catalog/session’)->addNotice(‘Notice text’). Here we see the use of ‘catalog/session‘ model (class Mage_Catalog_Model_Session). Let’s examine this model’s constructor:

//line 36 starts below
public function __construct()
{
	$this->init('catalog');
}

Tracing the init() method we’ll end up looking at Mage_Core_Model_Session_Abstract.

//line 82 starts below
public function init($namespace, $sessionName=null)
{
	parent::init($namespace, $sessionName);
	$this->addHost(true);
	return $this;
}

It’s init() method tells us that this storage mechanism is merely using different session namespace to store notification messages. On one side this can be seen as another way of complicating things while, but, on the other hand, it can be nice way of organizing things.

This kind of flexibility can be great, as you’re not limited to one storage mechanism. Instead of usingMage::getSingleton(‘core/session’), you could use something likeMage::getSingleton(‘myclass/my_model’).

You are also very flexible when it comes to outputting those notification messages. For instance, if we open catalog product view page:app/design/frontend/base/default/template/catalog/product/view.phtml

//line 39 starts below
 echo $this->getMessagesBlock()->getGroupedHtml() ?>

As we’re actually printing messages here, you could move this PHP code in your phtml file wherever you see fit.

That’s it for Magento’s notification system. As with everything, if you want to get a deeper insight as to what’s happening with some part of Magento, tracing the code is a way to go.